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DETAILED ACTION 



Response to Amendment 



1. This office action is in response to Applicants' Amendment of 19 March 2004. 

1.1 Claims 1-13, 17, 22, 29 and 31 are amended; Claims 32-33 are added. Claims 1-33 
remain pending. 

1.2 The prior art rejections and objections of record are withdrawn in response to Applicants' 
amendment 

1.3 The indicated allowability of Claim 29, as set forth in the office action of 12/19/2003, is 
maintained. 



1.4 Applicants' arguments of 19 March 2004 have been fully considered: they are found 
persuasive only to the extent that the approach, whereby parsing as claimed, is not specifically 
described by the prior art references of record. However, it is general knowledge that ' An XML 
parser is an information conversion tool, which converts DTMF code flow to XML data file and 
interfaces with D-Bus. Different services need different IVRs and different service procedure 
controls." Grooters (US Patent No. 6,684,399) discloses such marked-up language parsing 
feature for broadcasting on a network in Fig. 3. 



1.4.0 In response to Claims 1-33, Applicants allege, on page 21 last para., that the "Applicants' 
message is broadcast, and any receiver can choose to accept or disregard the message depending 
on contents, not on TCP-type routing information..." Examiner notes that this language is not 
incorporated, as limitations, into all the independent claims. 

1.4.1 In response to Claims 1-33, Applicants also allege, on page 22 1 st para., that the 
"Applicants' message to transmitted requires data special formatting.. ." Examiner notes that this 



Response to Arguments 



REMARKS 



• 
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language is not incorporated, as limitations, into all the independent claims, e.g., claims 5, 16, 
and 25. 

Claim Rejections - 35 USC § 101 

2. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions 
and requirements of this title. 

2.1 Claims 28-33 are rejected under 35 U.S.C. 101 as claiming 'data signal' which is non- 
statutory subject matter. 

Claim Rejections - 35 USC § 112 

3. The following is a quotation of the first and second paragraphs of 35 U.S.C. 1 12: 

1. The specification shall contain a written description of the invention, and of the manner and 
process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled 
in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

2. The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

3.1 Claims 1-4 are rejected under the first paragraph of 35 U.S.C. 112 for failing to 
describe the manner in which the two instances of a broadcast signal are created and how the 
selection of the broadcast signal to be transmitted is performed. Specifically, claim 1 refers to 
two instances of generating a broadcast signal, one in the preamble 'containing' plural 'bytes' 
and one in the fifth limitation 'formed' out of a 'frame' and 'integrity element.' 

3.2 Claims 1-4 are rejected under the second paragraph of 35 U.S.C. 112. It is unclear to 
the Examiner how the two instances of a broadcast signal are created and how the selection of 
the broadcast signal to be transmitted is performed. Specifically, claim 1 refers to two instances 
of generating a broadcast signal, one in the preamble 'containing' plural 'bytes' and one in the 
fifth limitation 'formed' out of a 'frame' and 'integrity element.' 
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Claim Objections 



3.3 The listed cl aims are objected to because of the following informalities: claim 12 refers 
to the terms "parsing said plurality...," claim 16 to "therewith, therebetween," which had not 
been previously defined. Appropriate corrections are required. 



4. Claim(s) 1-3 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 793 
- Transmission Control Protocol Specification (hereinafter TCP) in view of Grooters (US Patent 

No. 6,684,399). 

As per claim 1 . 

TCP substantially teaches of creating and transmitting data signals (i.e. 
segments/packets/frames) through a communication medium to receivers, see paragraph 1 of 
page 4. TCP further teaches of computing a checksum over the data, see Checksum paragraph 
on page 16. TCP further teaches of providing an integrity element, see pages 15-17, which the 
Examiner is interpreting as a header since it is essentially made of data (i.e. checksum, size, 
etc. . .) that will help determine the validity of the data frame. On pages 15-17, TCP teaches of an 
integrity element (header) that contains the checksum and how the integrity element (header) 
encapsulates (or associated with) one frame (or packet). On page 4, paragraph 3 teaches how the 
integrity element (header), specifically the checksum, can be used to determine if the received 
frame/data subset (or packet) is intact/valid or damaged. Further, in paragraph 1 of page 15, 
TCP teaches how the header and data are sent together as segments (i.e. broadcast signals). In 
paragraph 1 of page 4, TCP further teaches that the broadcast signals (i.e. segments) are 
transferred in both directions, hence TCP teaches the limitation of transmitting signals to 
receivers. In paragraph 6 of page 40, TCP further teaches of transmitting the signals over an 
established connection, hence TCP teaches the limitation of transmitting through communication 
medium to the device. 



Claim Rejections - 35 USC § 103 
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While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4, TCP fails to particularly mention the 
term: "parsing." 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup- language/XML documents.} Therefore, it would 
have been obvious to a person having ordinary skill in the art at the time the invention was made 
to modify the procedure in TCP by including therein a parsing technique as taught by Grooters, 
because such modification would provide the procedure disclosed in TCP with a technique 
whereby "content information is broken down and analyzed." {See Grooters, Fig. 3 at step 
326.} 

As per claim 2, 

TCP/Grooters further teaches of an integrity element (header) that comprises a size 
value, see page 17, paragraph 2 where the TCP length is described. Further, it would have been 
obvious to one of ordinary skill in the art to include both the checksum operation and seed value. 
If these values were not previously agreed upon by the communication devices, then one of 
ordinary skill in the art would obviously want to transmit these values so as to allow the 
receiving device to be able to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
disclosing known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
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XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not uniformly 
agreed upon beforehand so as to save bandwidth (i.e. have to transmit less bits) and save 
calculation time (i.e. immediately calculate checksum upon receiving as opposed to receiving the 
packet and read out the operation and then calculate the checksum). 

As per claim 3, 

Grooters does disclose marked-up-language/XML documents in Fig. 3 server 212 or 

network 222. Or equivalently, it would have been obvious to one of ordinary skill in the art at the 

time the invention was made to have the data signal contain an XML element. Essentially, this is 

akin to a user on a network, possibly the Internet, requesting an XML document (which 

obviously contains XML elements), having the document framed (or packeted up) and 

transmitted off to the receiver. Simply put, the data that the frame/packet contains can be 

comprised of almost any type of transferable data, (i.e. XML document with XML elements, 

HTML document etc). Also see Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 

executed for broadcasting data/HTML/markup- language/XML documents. 

4.1 Claim(s) 4 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 793 - 
Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US Patent No. 
6,684,399) in view of admitted prior art "Specifications" (hereinafter Specs). 

As per claim 4, 

TCP/Grooters as noted above in claim 1 and later in claim 3 substantially teaches of the 
limitations of claim 4. TCP/Grooters does not teach of transmitting the signal as a diffuse 
infrared signal. Nonetheless, TCP/Grooters does teach of establishing communication 
connections. 
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Specs, in an analogous art, teaches of diffuse optical communication as a common optical 
communication protocol, see paragraph 88 on page 28. 

It would have been obvious to one of ordinary skill in the art at the time the invention 

was made to transmit the frames/packets/broadcast signal of TCP/Grooters using the optical 

communication protocol. This modification would have been obvious because one of ordinary 

skill in the art would have been motivated by the suggestion provided by Specs that diffuse 

optical communication protocol is a commonly used protocol and hence communication method. 

4.2 Claimfs) 5-9 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 793 
- Transmission Control Protocol Specification (hereinafter TCP) in view of Grooters (US Patent 

No. 6,684,399). 

As per claim 5, 

TCP substantially teaches of exchanging (and hence transmitting and receiving) 
segments/packets/data signals having a plurality of bytes in paragraph 1 of page 4 and paragraph 
6 of page 40. TCP further teaches of creating frames/packets and headers (integrity elements) to 
transmit data, see paragraph 1 on page 4 and pages 15-17, and of using the checksum to ensure 
reliability, see paragraph 3, page 4. By teaching of creating the data and 
communicating/transferring it in a specific manner, the Examiner is interpreting that TCP is 
teaching of both how to send and receive the data. When read in this light, it is clear that if TCP 
teaches of how to create frames (packets) and associated integrity elements (headers) and how to 
combine the frames and integrity elements (i.e. append the header to the packet), then TCP 
teaches how to detect and separate packets/frames as well. Further, with TCP teaching of 
headers and what they are comprised of on pages 15-17, it is clear that TCP teaches of 
determining the contents of the integrity element (header). Further, TCP explicitly teaches of 
using the checksum (which is one of the contents of the header/integrity element) to disregard 
damaged segments/packets, see paragraph 3 on page 4. 
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While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4 and means to reverse such frame 
packeting or packaging, TCP fails to particularly mention that such frame reversal is for 
reverting a "parsing" routine. 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing 
routine/reversal-thereof is executed for broadcasting data/HTML/markup-language/XML 
documents.} Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify the procedure in TCP by including therein a 
parsing technique as taught by Grooters, because such modification would provide the 
procedure disclosed in TCP with a technique whereby "content information is broken down and 
analyzed." {See Grooters, Fig. 3 at step 326.} 

As per claim 6, 

TCP/Grooters substantially teaches, as noted above in claim 5, the limitations of claim 6. 

With respect to the limitations of claim 6, TCP further teaches of a checksum that is 
calculated over its associated frame/packet, see pages 15-17 and specifically the Checksum 
paragraph of page 16. 

As per claims 7 and 8, 

TCP/Grooters substantially teaches, as noted above in claim 5, the limitations of claim 7. 

With respect to the limitations of claim 7, TCP further teaches of checking a checksum at 
the receiver to ensure that the segment is not damaged, see paragraph 3 of page 4. Clearly, if the 
checksum is calculated upon receipt and matches the transmitted checksum, then the 
segment/frame/packet will be validated, otherwise, when the two checksums don't match, the 
"damaged" one will be discarded or invalidated. 
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As per claim 9, 

TCP/Grooters substantially teaches, as noted above in claim 5, the limitations of claim 9. 

With respect to the limitations of claim 9, TCP further teaches of an integrity element 
(header) that comprises a size value, see page 17, paragraph 2 where the TCP length is described. 
Further, it would have been obvious to one of ordinary skill in the art to include both the 
checksum operation and seed value. If these values were not previously agreed upon by the 
communication devices, then one of ordinary skill in the art would obviously want to transmit 
these values so as to allow the receiving device to be able to calculate the checksum and 
validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
disclosing known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not uniformly 
agreed upon beforehand so as to save bandwidth (i.e. have to transmit less bits) and save 
calculation time (i.e. immediately calculate checksum upon receiving as opposed to receiving the 
packet and read out the operation and then calculate the checksum). 

4.3 Claim(s) 10 and 11 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US 
Patent No. 6,684,399) in view of admitted prior art "Specifications" (hereinafter Specs). 
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As per claim 10 

TCP/Grooters, as noted above in claim 5, substantially teaches of the limitations of 
claim 10. TCP/Grooters does not teach of transmitting the signal as a diffuse infrared signal. 
Nonetheless, TCP/Grooters does teach of establishing communication connections. 

Specs, in an analogous art, teaches of diffuse optical communication as a common optical 
communication protocol, see lines 3-6 of paragraph 88 on page 28. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to transmit the frames/packets/broadcast signal of TCP/Grooters using the optical 
communication protocol. This modification would have been obvious because one of ordinary 
skill in the art would have been motivated by the suggestion provided by Specs that diffuse 
optical communication protocol is a commonly used protocol and hence communication method. 

As per claim 11, 

TCP/Grooters, as noted above in claim 5 and later in claim 10, substantially teaches of 
the limitations of claim 11. TCP/Grooters does not teach of data signal being created by 
modulating an electric light. 

Specs, in an analogous art, teaches of modulating an electric light to generate optical 
signals as being known in the art, see lines 1-5 of paragraph 161 of page 55. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to create frames/packets/broadcast signal of TCP/Grooters by modulating an electric 
light. This modification would have been obvious to one of ordinary skill in the art would 
because one skilled in the art would have known of the techniques as mentioned by Specs. 
Further, since Specs discloses that the techniques are known in the art, one skilled in the art 
would readily be able to modulate light so as to generate the optical signals with which the data 
signals are transferred over. 
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4.4 Claim(s) 12 J 3 and 15 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) in view of Grooters 
(US Patent No. 6,684,399). 

As per claim 12, 

TCP substantially teaches of creating and transmitting data signals (i.e. packets/frames) 
through a communication medium to receivers see paragraph 1 of page 4. TCP further teaches 
of computing a checksum over the data, see Checksum paragraph on page 16. TCP further 
teaches of providing an integrity element, see pages 15-17, which the Examiner is interpreting as 
a header since it is essentially made of data (i.e. checksum, size, etc..) that will help determine 
the validity of the data frame. On pages 15-17, TCP teaches of an integrity element (header) that 
contains the checksum and how the integrity element (header) encapsulates (or associated with) 
one frame (or packet). On page 4, paragraph 3 teaches how the integrity element (header), 
specifically the checksum, can be used to determine if the received frame/data subset (or packet) 
is intact/valid or damaged. Further, in paragraph 1 of page 15, TCP teaches how the header and 
data are sent together as segments (i.e. broadcast signals). In paragraph 1 of page 4, TCP further 
teaches that the broadcast signals (i.e. segments) are transferred in both directions, hence TCP 
teaches the limitation of transmitting signals to receivers. In paragraph 6 of page 40, TCP further 
teaches of transmitting the signals over an established connection, hence TCP teaches the 
limitation of transmitting through communication medium to the device. 

While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4, TCP fails to particularly mention the 
term: "parsing." 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup-language/XML documents.} Therefore, it would 
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have been obvious to a person having ordinary skill in the art at the time the invention was made 
to modify the procedure in TCP by including therein a parsing technique as taught by Grooters, 
because such modification would provide the procedure disclosed in TCP with a technique 
whereby "content information is broken down and analyzed." {See Grooters, Fig. 3 at step 
326.} 

While TCP/Grooters does not explicitly teach of making the transmission available for 
handheld devices, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to make the broadcast signal available for a handheld device. Handheld 
devices (i.e. PDAs) are essentially handheld computers that can process information whether 
received via their infrared port or through their physical port. One skilled in the art would 
obviously want a handheld device to be able to receive information so as to be able to 
communicate with it. 

Further, while TCP does not explicitly teach of apparatuses, devices, or computer 
readable executable code embedded to carry out the methods taught, Grooters does in Fig. 3 
server 212. Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to implement the teachings in some type of hardware or computer 
executable code once the method is known/determined. 

As per claim 13. 

Grooters does disclose marked-up-language/XML documents in Fig. 3 server 212 or 
network 222. Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the Internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can be 
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comprised of almost any type of transferable data, (i.e. XML document with XML elements, 
HTML document etc). 
As per claim 15, 

TCP further teaches of an integrity element (header) that comprises a size value, see page 
17, paragraph 2 where the TCP length is described. Further, it would have been obvious to one 
of ordinary skill in the art to include both the checksum operation and seed value. If these values 
were not previously agreed upon by the communication devices, then one of ordinary skill in the 
art would obviously want to transmit these values so as to allow the receiving device to be able 
to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
speaking known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

4.5 Claims 14 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 793 - 
Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US Patent No. 
6,684,399) in view of admitted prior art "Specifications" (hereinafter Specs). 

As per claim 14, 

TCP/Grooters as noted above in claim 12 substantially teaches of the limitations of 
claim 14. TCP/Grooters does not teach of transmitting the signal as a diffuse infrared signal. 
Nonetheless, TCP/Grooters does teach of establishing communication connections. 

Specs, in an analogous art, teaches of diffuse optical communication as a common optical 
communication protocol, see paragraph 88 on page 28. 
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It would have been obvious to one of ordinary skill in the art at the time the invention 

was made to transmit the frames/packets/broadcast signal of TCP using the optical 

communication protocol. This modification would have been obvious because one of ordinary 

skill in the art would have been motivated by the suggestion provided by Specs that diffuse 

optical communication protocol is a commonly used protocol and hence communication method. 

4.6 Claim(s) 16-19 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 
793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US Patent 

No. 6,684,399). 

As per claim 16, 

TCP substantially teaches of exchanging (and hence transmitting and receiving) 
segments/packets/data signals having a plurality of bytes in paragraph 1 of page 4 and paragraph 
6 of page 40. TCP further teaches of creating frames/packets and headers (integrity elements) to 
transmit data, see paragraph 1 on page 4 and pages 15-17 and of using the checksum to ensure 
reliability , see paragraph 3, page 4. By teaching of creating the data and 
communicating/transferring it in a specific manner, the Examiner is interpreting that TCP is 
teaching of both how to send and receive the data. When read in this light, it is clear that if TCP 
teaches of how to create frames (packets) and associated integrity elements (headers) and how to 
combine the frames and integrity elements (i.e. append the header to the packet), then TCP 
teaches how to detect and separate packets as well. Further, with TCP teaching of headers and 
what they are comprised of on pages 15-17, it is clear that TCP teaches of determining the 
contents of the integrity element (header). Further, TCP explicitly teaches of using the checksum 
(which is one of the contents of the header/integrity element) to disregard damaged 
segments/packets, see paragraph 3 on page 4. TCP further teaches of a checksum that is 
calculated over its associated frame/packet, see pages 15-17 and specifically the Checksum 
paragraph of page 16. TCP further teaches of checking a checksum at the receiver to ensure that 
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the segment is not damaged, see paragraph 3 of page 4. Clearly, if the checksum is calculated 
upon receipt and matches the transmitted checksum, then the segment/frame/packet will be 
validated, otherwise, when the two checksums don't match, the "damaged" one will be discarded 
or invalidated. Further, TCP teaches of passing the frames/segments/packets on if the 
checksums match, see paragraph 3 of page 4, specifically where TCP mentions discarding 
damaged segments (i.e. segments in which the checksums do not match) and keeping/passing on 
those that do match. 

While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4 and means to reverse such frame 
packeting or packaging, TCP fails to particularly mention that such frame reversal is for 
reverting a "parsing" routine. 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing 
routine/reversal-thereof is executed for broadcasting data/HTML/markup-language/XML 
documents.} 

While TCP does not explicitly teach of apparatuses, devices, or computer readable 
executable code embedded to carry out the methods taught, it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to implement the teachings in some 
type of hardware or computer executable code once the method is known/determined. 

As per claim 17, 

Grooters does disclose marked-up-language/XML documents in Fig. 3 server 212 or 
network 222. Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the Internet, requesting an XML document (which 
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obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can be 
comprised of almost any type of transferable data, (i.e. XML document with XML elements, 
HTML document etc). Also see Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup-language/XML documents. 
As per claim 18, 

TCP further teaches of discarding the frames/segments/packets on if the checksums 
match, see paragraph 3 of page 4, specifically where TCP mentions discarding damaged 
segments (i.e. segments in which the checksums do not match). 

As per claim 19, 

TCP further teaches of an integrity element (header) that comprises a size value, see page 
17, paragraph 2 where the TCP length is described. Further, it would have been obvious to one 
of ordinary skill in the art to include both the checksum operation and seed value. If these values 
were not previously agreed upon by the communication devices, then one of ordinary skill in the 
art would obviously want to transmit these values so as to allow the receiving device to be able 
to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
speaking known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 



Application/Control Number: 09/930,004 Page 16 of 25 

Art Unit: 2133 

It is further unclear why the checksum operation and seed values are not uniformly 
agreed upon beforehand so as to save bandwidth (i.e. have to transmit less bits) and save 
calculation time (i.e. immediately calculate checksum upon receiving as opposed to receiving the 
packet and read out the operation and then calculate the checksum). 

4.7 Claimfs) 20-22 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 
793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US Patent 
No. 6,684,399). 

As per claim 20, 

TCP substantially teaches of creating and transmitting data signals (i.e. packets/frames) 
through a communication medium to receivers see paragraph 1 of page 4. TCP further teaches 
of parsing (or packeting or packaging) bytes into frames (or packets) containing a subset of the 
bytes, see paragraph 1 of page 4. TCP further teaches of computing a checksum over the data, 
see Checksum paragraph on page 16. TCP further teaches of providing an integrity element, see 
pages 15-17, which the Examiner is interpreting as a header since it is essentially made of data 
(i.e. checksum, size, etc. . .) that will help determine the validity of the data frame. On pages 15- 
17, TCP teaches of an integrity element (header) that contains the checksum and how the 
integrity element (header) encapsulates (or associated with) one frame (or packet). On page 4, 
paragraph 3 teaches how the integrity element (header), specifically the checksum, can be used 
to determine if the received frame/data subset (or packet) is intact/valid or damaged. Further, in 
paragraph 1 of page 15, TCP teaches how the header and data are sent together as segments (i.e. 
broadcast signals). In paragraph 1 of page 4, TCP further teaches that the broadcast signals (i.e. 
segments) are transferred in both directions, hence TCP teaches the limitation of transmitting 
signals to receivers. In paragraph 6 of page 40, TCP further teaches of transmitting the signals 
over an established connection, hence TCP teaches the limitation of transmitting through 
communication medium to the device. 
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While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4, TCP fails to particularly mention the 
term: "parsing." 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup-language/XML documents.} Therefore, it would 
have been obvious to a person having ordinary skill in the art at the time the invention was made 
to modify the procedure in TCP by including therein a parsing technique as taught by Grooters, 
because such modification would provide the procedure disclosed in TCP with a technique 
whereby "content information is broken down and analyzed'' {See Grooters, Fig. 3 at step 
326.} 

While TCP does not explicitly teach of making the broadcast signal available for 
transmission to a receiving device, Grooters does disclose such data transfer in Fig. 3 server 212 
or network 222. Or equivalently, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to make the broadcast signal available for the transmission. 
TCP, in paragraph 6 of page 40, does teach of a connection that is established and data is 
communicated between senders and receivers. Therefore making the signal available for 
transmission to a receiving device must occur since TCP teaches that a connection is established 
and data/segments are communicated/exchanged. 

As per claim 21, 

TCP further teaches of an integrity element (header) that comprises a size value, see page 
17, paragraph 2 where the TCP length is described. Further, it would have been obvious to one 
of ordinary skill in the art to include both the checksum operation and seed value. If these values 
were not previously agreed upon by the communication devices, then one of ordinary skill in the 
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art would obviously want to transmit these values so as to allow the receiving device to be able 
to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
speaking known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not uniformly 
agreed upon beforehand so as to save bandwidth (i.e. have to transmit less bits) and save 
calculation time (i.e. immediately calculate checksum upon receiving as opposed to receiving the 
packet and read out the operation and then calculate the checksum). 

As per claim 22. 

Grooters does disclose marked-up-language/XML documents in Fig. 3 server 212 or 
network 222. Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the Internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can be 
comprised of almost any type of transferable data, (i.e. XML document with XML elements, 
HTML document etc). 

4.8 Claimfs) 23 and 24 is/are rejected under 35 U.S. C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US 
Patent No. 6,684,399) in view of admitted prior art "Specifications" (hereinafter Specs). 
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As per claim 23 

TCP/Grooters, as taught above in claim 20, substantially teaches of the limitations of 
claim 23. TCP, however, does not teach of transmitting the signal as a diffuse infrared signal. 
Nonetheless, TCP/Grooters does teach of establishing communication connections. 

Specs, in an analogous art, teaches of diffuse optical communication as a common optical 
communication protocol, see line see lines 3-6 of paragraph 88 on page 28. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to transmit the frames/packets/broadcast signal of TCP/Grooters using the optical 
communication protocol. This modification would have been obvious because one of ordinary 
skill in the art would have been motivated by the suggestion provided by Specs that diffuse 
optical communication protocol is a commonly used protocol and hence communication method. 

As per claim 24, 

TCP/Grooters, as taught above in claim 20, substantially teaches of the limitations of 
claim 24. TCP/Grooters does not teach of data signal being created by modulating an electric 
light. 

Specs, in an analogous art, teaches of modulating an electric light to generate optical 
signals as being known in the art, see line see lines 1-5 of paragraph 161 of page 55. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to create frames/packets/broadcast signal of TCP/Grooters by modulating an electric 
light. This modification would have been obvious to one of ordinary skill in the art would 
because one skilled in the art would have known of the techniques as mentioned by Specs. 
Further, since Specs discloses that the techniques are known in the art, one skilled in the art 
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would readily be able to modulate light so as to generate the optical signals with which the data 
signals are transferred over. 

4.9 Claim(s) 25-27 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 
793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US Patent 
No. 6,684,399). 

As per claim 25, 

TCP substantially teaches of exchanging (and hence transmitting and receiving) 
segments/packets/data signals having a plurality of bytes in paragraph 1 of page 4 and paragraph 
6 of page 40. TCP further teaches of creating frames/packets and headers (integrity elements) to 
transmit data, see paragraph 1 on page 4 and pages 15-17 and of using the checksum to ensure 
reliability, see paragraph 3, page 4. By teaching of creating the data and 
communicating/transferring it in a specific manner, the Examiner is interpreting that TCP is 
teaching of both how to send and receive the data. When read in this light, it is clear that if TCP 
teaches of how to create frames (packets) and associated integrity elements (headers) and how to 
combine the frames and integrity elements (i.e. append the header to the packet), then TCP 
teaches how to detect and separate packets as well. Further, with TCP teaching of headers and 
what they are comprised of on pages 15-17, it is clear that TCP teaches of determining the 
contents of the integrity element (header). Further, TCP explicitly teaches of using the checksum 
(which is one of the contents of the header/integrity element) to disregard damaged 
segments/packets, see paragraph 3 on page 4. 

While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4 and means to reverse such frame 
packeting or packaging, TCP fails to particularly mention that such frame reversal is for 
reverting a "parsing" routine. 
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However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id, Fig. 3 at step 326 wherein parsing 
routine/reversal-thereof is executed for broadcasting data/HTML/markup-language/XML 
documents.} 

As per claims 26 and 27, 

TCP substantially teaches, as noted above in claim 25, the limitations of claims 26 and 
27. With respect to the limitations of claims 26 and 27, TCP further teaches of checking a 
checksum at the receiver to ensure that the segment is not damaged, see paragraph 3 of page 4. 
Clearly, if the checksum is calculated upon receipt and matches the transmitted checksum, then 
the segment/frame/packet will be validated, otherwise, when the two checksums don't match, the 
"damaged" one will be discarded or invalidated. 

4.10 Claim(s) 28 and 30-31 is/are rejected under 35 U.S. C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US 
Patent No. 6,684,399). 

As per claim 28. 

TCP substantially teaches of creating and transmitting data signals (i.e. packets/frames) 
through a communication medium to receivers see paragraph 1 of page 4. TCP further teaches 
of computing a checksum over the data, see Checksum paragraph on page 16. TCP further 
teaches of providing an integrity element, see pages 15-17, which the Examiner is interpreting as 
a header since it is essentially made of data (i.e. checksum, size, etc..) that will help determine 
the validity of the data frame. On pages 15-17, TCP teaches of an integrity element (header) that 
contains the checksum and how the integrity element (header) encapsulates (or associated with) 
one frame (or packet). On page 4, paragraph 3 teaches how the integrity element (header), 
specifically the checksum, can be used to determine if the received frame/data subset (or packet) 
is intact/valid or damaged. Further, in paragraph 1 of page 15, TCP teaches how the header and 



Application/Control Number: 09/930,004 Page 22 of 25 

Art Unit: 2133 

data are sent together as segments (i.e. broadcast signals). In paragraph 1 of page 4, TCP further 
teaches that the broadcast signals (i.e. segments) are transferred in both directions, hence TCP 
teaches the limitation of transmitting signals to receivers. TCP further teaches of checking a 
checksum at the receiver to ensure that the segment is not damaged, see paragraph 3 of page 4. 
Clearly, if the checksum is calculated upon receipt and matches the transmitted checksum, then 
the segment/frame/packet will be validated, otherwise, when the two checksums don't match, the 
"damaged" one will be discarded or invalidated. 

While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4 and means to reverse such frame 
packeting or packaging, TCP fails to particularly mention that such frame reversal is for 
reverting a "parsing" routine. 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing 
routine/reversal-thereof is executed for broadcasting data/HTML/markup-language/XML 
documents.} Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify the procedure in TCP by including therein a 
parsing technique as taught by Grooters, because such modification would provide the 
procedure disclosed in TCP with a technique whereby "content information is broken down and 
analyzed'' {See Grooters, Fig. 3 at step 326.} 

While TCP/Grooters does not explicitly teach of the data signal being used to modify 
the operation of the receiving device, TCP does teach of the use of acknowledgements (ACKs) to 
inform the sender that a packet has been received, see paragraph 1 of page 10, and of the use of 
PUSH commands, see paragraphs 5-7 of page 12, to change (modify) the operation of the 
receiver to "push" the data immediately. Therefore, through the use of ACKs to inform the 
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receiver to send newer, or older segments, and the use of PUSH commands to pass the data on 
immediately, TCP teaches of modifying the operation of the receiver (and sender too). 
As per claim 30, 

TCP/Grooters further teaches of an integrity element (header) that comprises a size 
value, see page 17, paragraph 2 where the TCP length is described. Further, it would have been 
obvious to one of ordinary skill in the art to include both the checksum operation and seed value. 
If these values were not previously agreed upon by the communication devices, then one of 
ordinary skill in the art would obviously want to transmit these values so as to allow the 
receiving device to be able to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
speaking known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not uniformly 
agreed upon beforehand so as to save bandwidth (i.e. have to transmit less bits) and save 
calculation time (i.e. immediately calculate checksum upon receiving as opposed to receiving the 
packet and read out the operation and then calculate the checksum). 

As per claim 31, 

Grooters does disclose marked-up-language/XML documents in Fig. 3 server 212 or 
network 222. Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to have the data signal contain an XML element. Essentially, this is 
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akin to a user on a network, possibly the Internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can be 
comprised of almost any type of transferable data, (i.e. XML document with XML elements, 
HTML document etc). Also see Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup-language/XML documents. 

Allowable Subject Matter 

5, Claims 29 and 32-33 are allowable over the prior art and would be allowed if rewritten to 
overcome the previously stipulated rejections under 35 USC 101. 

5.1 Any comments considered necessary by applicant must be submitted no later than the 
payment of the issue fee and, to avoid processing delays, should preferably accompany the issue 
fee. Such submissions should be clearly labeled "Comments on Statement of Reasons for 
Allowance." 

Conclusion 

6, The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

6,1 Any response to this action should be mailed to: 

Commissioner of Patents and Trademarks, Washington, D.C. 20231 
or faxed to: (703) 872-9306 for all formal communications. 

Hand-delivered responses should be brought to Crystal Park II, 2121 Crystal Drive, 
Arlington, VA, Fourth Floor (Receptionist). 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Guy J. Lamarre, P.E., whose telephone number is (703) 305- 
0755. The examiner can normally be reached on Monday to Friday from 9:30 AM to 6:00 PM. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Albert De Cady, can be reached on (703) 305-9595. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the Group receptionist whose telephone number is (703) 305-3900. 

Information regarding the status of an application may also be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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Primary Examiner 
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